Hi @marcstern ,

Could you please have a look at the exchange here: #2214

... and share your thoughts as relates to this new PR. Although that PR was for ModSecurity v3, the observations there may be pertinent.

In brief, at the time it appeared that both nginx and Apache ignore any filename* specification. In which case if ModSecurity were to prefer that value over filename=, it could create misleading results.

@marcstern ?

Sorry, I didn't receive the notification.
Maybe Apache/Nginx don't support filename*, but some back-end applications do, so they're vulnérable to injection in filename* if it's not parsed.
From a pure security point of view, the best would maybe be to store both in the FILES collection, so we're sure we check everything.

On top of that, a rule checking that filename is always present when providing filename* may be a good idea. Can we find some data about this behaviour?

Unfortunately, the storage of the FILES entries is done outside the header parsing, so only one name can be set inside the existing code.
If someone has an idea to easily add all filenames, please shoot.

Hi @marcstern ,

It sounds like you agree that we should not proceed with this PR.

With both of the two most widely used web servers ignoring filename*, this PR would produce misleading results.

You are correct that an Apache server with ModSecurity might be a reverse proxy sending requests to some non-Apache, non-nginx web severs that do process filename*, so that use case can be considered.

Partly for the reason you noted yourself, I don't think it's practical/advisable, within the existing framework of ModSecurity variables/collections, to add both the value of filename and filename* if both are present.

Note also, that with the introduction of the MULTIPART_PART_HEADERS collection, it is possible to write some rules that can check for various scenarios (if both are present, etc.)

There could be the remaining issue that the multipart parser in ModSecurity v2 would react to a Content-Disposition part header containing filename* by raising a parser error. An implementation that addresses that could perhaps be considered (i.e. a comparable implementation as to what was done in ModSecurity v3).

However, before considering even that, it might be useful to know just how broad the problem space is. The most recent word on filename* that I have seen is from RFC7578 :

NOTE: The encoding method described in [RFC5987], which would add a "filename*" parameter to the Content-Disposition header field, MUST NOT be used.

Indeed, this PR should be ignored.
Probably a rule to forbid a "filename*" parameter would be better, as it's no more standard.